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Abstract. We study sequential programs that are instruction sequences 
with dynamically instantiated instructions. We define the meaning of 
such programs in two different ways. In either case, we give a trans- 
lation by which each program with dynamically instantiated instruc- 
tions is turned into a program without them that exhibits on execution 
the same behaviour by interaction with some service. The complexity of 
the translations differ considerably, whereas the services concerned are 
equally simple. However, the service concerned in the case of the simpler 
translation is far more powerful than the service concerned in the other 
case. 
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1 Introduction 

In this paper, we study sequential programs that are instruction sequences with 
dynamically instantiated instructions. With that we carry on the line of research 
with which a start was made in [3]. The object pursued with this line of research 
is the development of a theoretical understanding of possible forms of sequential 
programs, starting from the simplest form. The view is taken that sequential 
programs in the simplest form are sequences of instructions. Program algebra, 
an algebra of programs in which programs are looked upon as sequences of 
instructions, is taken for the basis of the development aimed at. 

The approach to define the meaning of programs followed in this line of re- 
search is called projection semantics. It explains the meaning of programs in 
terms of known programs instead of more or less sophisticated mathematical 
objects that represent behaviours of programs under execution. The main ad- 
vantage of projection semantics is that it does not require a lot of mathematical 

* This research was partly carried out in the framework of the Jacquard-pro ject Sym- 
biosis, which is funded by the Netherlands Organisation for Scientific Research 
(NWO). 



background. Over and above that, the view is taken that the behaviours of se- 
quential programs under execution arc threads as considered in basic thread 
algebra [3]. 1 Therefore, the meaning of the programs considered in program al- 
gebra is explained in terms of threads. The experience gained so far leads us 
to believe that sequential programs arc nothing but linear representations of 
threads. 

Sequential programs in the form of assembly programs up to and includ- 
ing sequential programs in the form of structured programs are covered in [3]. 
However, although they are found in existing assembly programming practice, 
indirect jump instructions are not considered. In [5], several kinds of indirect 
jump instructions are considered, including a kind by which recursive method 
calls can easily be explained. Dynamic instruction instantiation is a programming 
feature that is not suggested by existing programming practice. However, from 
the viewpoint that sequential programs are nothing but linear representations of 
threads, it is a genuine programming feature. It is a useful programming feature 
as well, as will be illustrated by means of an example in the paper. Therefore, we 
consider a theoretical understanding of instruction sequences with dynamically 
instantiated instructions relevant to programming. 

We believe that interaction with services provided by an execution environ- 
ment is inherent in the behaviour of programs under execution. Intuitively, some 
service provides for dynamic instruction instantiation. In this paper, we define 
the meaning of programs with dynamically instantiated instructions in two dif- 
ferent ways. In either case, we give a translation by which each program with 
dynamically instantiated instructions is turned into a program without them 
that exhibits on execution the same behaviour by interaction with some service. 
In one case, the service concerned provides in effect for the dynamic instruc- 
tion instantiation and, in the other case, it is largely achieved by the translated 
programs. We consider it useful to treat both cases because of the considerable 
difference in complexity of the two translations. 

A thread proceeds by doing steps in a sequential fashion. A thread may do 
certain steps only for the sake of having itself affected by some service. The 
interaction between behaviours of programs under execution and some service 
referred to above is an interaction with that purpose. In [7], the use mechanism 
is introduced to allow for such a kind of interaction between threads and ser- 
vices. In this paper, we will use a generalization of the use mechanism, called 
the action transforming use mechanism, to have behaviours of programs under 
execution affected by services. This generalization is reminiscent of the state 
operator introduced in [1] . 

A hierarchy of program notations rooted in program algebra is introduced 
in [3]. In this paper, we embroider on one program notation that belongs to 
this hierarchy. The program notation in question, called PGLD, is a very simple 
program notation which is close to existing assembly languages. The hierarchy 

1 In [3], basic thread algebra is introduced under the name basic polarized process 
algebra. Prompted by the development of thread algebra [7], which is a design on 
top of it, basic polarized process algebra has been renamed to basic thread algebra. 
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also includes a program notation, called PGLS, that supports structured pro- 
gramming by offering a rendering of conditional and loop constructs instead of 
(unstructured) jump instructions. Each PGLS program can be translated into a 
semantically equivalent PGLD program by means of the projection semantics of 
PGLS and some intermediate program notations. 

This paper is organized as follows. First, we review basic thread algebra, 
program algebra, and program notation PGLD (Sections 2, 3, and 4). Next, we 
provide a simple classification of services that will be used in subsequent sec- 
tions (Section 5). After that, we extend basic thread algebra with the action 
transforming use mechanism and introduce a state-based approach to describe 
services (Sections 6 and 7). Then, we give a state-based description of a service 
that can provide for dynamic instruction instantiation and use that service to de- 
fine the meaning of the programs from a variant of the program notation PGLD 
with dynamically instantiated instructions (Sections 8 and 9). Following this, 
we introduce a concrete notation for basic instructions that covers dynamically 
instantiated instructions and use that notation to illustrate the usefulness of dy- 
namic instruction instantiation (Section 10). Thereupon, we give a state-based 
description of a register file service and use that service to define the meaning of 
the programs from the variant of the program notation PGLD with dynamically 
instantiated instructions in another way (Sections 11 and 12). Finally, we dis- 
cuss the semantic approaches followed in the preceding sections and make some 
concluding remarks (Sections 13 and 14). 

2 Basic Thread Algebra 

In this section, we review BTA (Basic Thread Algebra), a form of process algebra 
which is concerned with the behaviours that sequential programs exhibit on 
execution. The behaviours concerned are called threads. BTA was first presented 
in [3]. In that paper, as well as several other papers, BTA is called BPPA (Basic 
Polarized Process Algebra). 

In BTA, it is assumed that there is a fixed but arbitrary finite set of basic 
actions A with tau ^ A. We write A tau f° r -4 LI {tau}. The members of A t3U are 
referred to as actions. 

A thread performs basic actions in a sequential fashion. The intuition is 
that each basic action performed by a thread is taken as a command to be 
processed by a service provided by the execution environment of the thread. The 
processing of a command may involve a change of state of the service concerned. 
At completion of the processing of the command, the service produces a reply 
value and returns that reply value to the thread. The reply value is either T or 
F and determines how the thread proceeds. 

Although BTA is one-sorted, we make this sort explicit. The reason for this 
is that we will extend BTA with an additional sort in Section 6. 

The algebraic theory BTA has one sort: the sort T of threads. To build terms 
of sort T, BTA has the following constants and operators: 

- the inaction constant D : T; 
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Table 1. Axiom of BTA 



x < tau > y = x < tau > x Tl 



— the termination constant S : T; 

- for each a G Aau, the binary postconditional composition operator _ < a > 
_ : T x T -> T. 

Terms of sort T are built as usual (see e.g. [16, 17]). Throughout the paper, we 
assume that there are infinitely many variables of sort T, including x,y, z. 

We use infix notation for postconditional composition. We introduce action 
prefixing as an abbreviation: a o p, where p is a term of sort T, abbreviates 
P <! a > p. 

The thread denoted by a closed term of the form p < a > g will first perform 
a, and then proceed as the thread denoted by p if the processing of a leads to the 
reply T (called a positive reply) and proceed as the thread denoted by q if the 
processing of a leads to the reply F (called a negative reply). The action tau plays 
a special role. It is a concrete internal action: the processing of tau will never 
involve a state change and always lead to a positive reply, but notwithstanding all 
that its presence matters. The threads denoted by D and S will become inactive 
and terminate, respectively. 

BTA has only one axiom. This axiom is given in Table 1. Using the abbrevia- 
tion introduced above, axiom Tl can be written as follows: x < tau >y = tau ox. 

Each closed BTA term of sort T denotes a finite thread, i.e. a thread that 
will become inactive or terminate after it has performed finitely many actions. 
Infinite threads can be described by guarded recursion specifications. 

A guarded recursive specification over BTA is a set of recursion equations 
E = {X = px 1 £ V}, where V is a set of variables of sort T and each px 
is a term of the form D, S or p < a l> q with p and q BTA terms of sort T that 
contain only variables from V. We write V(E) for the set of all variables that 
occur on the left-hand side of an equation in E. We are only interested in models 
of BTA in which guarded recursive specifications have unique solutions, such as 
the projective limit model of BTA presented in [2]. A thread that is the solution 
of a finite guarded recursive specification over BTA is called a finite-state thread. 

We extend BTA with guarded recursion by adding constants for solutions 
of guarded recursive specifications and axioms concerning these additional con- 
stants. For each guarded recursive specification E and each X 6 X(E), we add a 
constant of sort T standing for the unique solution of E for X to the constants 
of BTA. The constant standing for the unique solution of E for X is denoted by 
(X\E). Moreover, we add the axioms for guarded recursion given in Table 2 to 
BTA, where we write (tx\E) for tx with, for all Y E V{E), all occurrences of 
Y in tx replaced by (Y\E). In this table, X, tx and E stand for an arbitrary 
variable of sort T, an arbitrary BTA term of sort T and an arbitrary guarded 
recursive specification over BTA, respectively. Side conditions are added to re- 
strict the variables, terms and guarded recursive specifications for which X, tx 
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Table 2. Axioms for guarded recursion 



(X\E) = (t x \E) if X = t x G E RDP 
E X = if X G V(£) RSP 



and £7 stand. RDP stands for recursive definition principle and RSP stands for 
recursive specification principle. The equations (X\E) = (tx\E) for a fixed E 
express that the constants (X\E) make up a solution of E. The conditional equa- 
tions E =>■ X = (X\E) express that this solution is the only one. It is easily 
demonstrated that RDP and RSP hold in the model of BTA based on projective 
sequences outlined in [3] (cf. Theorem 1 from [8]). 

We will use the following abbreviation: a w , where a G Aau, abbreviates 
(X\{X = aoX}). 

We will write BTA+REC for BTA extended with the constants for solutions 
of guarded recursive specifications and axioms RDP and RSP. 

In [4], we show that the threads considered in BTA+REC can be viewed as 
processes that are definable over ACP [12]. 

3 Program Algebra 

In this section, we review PGA (ProGram Algebra), an algebra of sequential 
programs based on the idea that sequential programs are in essence sequences 
of instructions. PGA provides a program notation for finite-state threads. 

In PGA, it is assumed that there is a fixed but arbitrary finite set 21 of basic 
instructions. PGA has the following primitive instructions: 

— for each a € 21, a plain basic instruction a; 

— for each a € 21, a positive test instruction +a; 

— for each a G 21, a negative test instruction —a; 

— for each I G N, a forward jump instruction #Z; 

— a termination instruction !. 

We write 3 for the set of all primitive instructions. 

The intuition is that the execution of a basic instruction a may modify a 
state and produces T or F at its completion. In the case of a positive test in- 
struction +o, basic instruction a is executed and execution proceeds with the 
next primitive instruction if T is produced; otherwise, the next primitive instruc- 
tion is skipped and execution proceeds with the primitive instruction following 
the skipped one. In the case where T is produced and there is not at least one 
subsequent primitive instruction and in the case where F is produced and there 
are not at least two subsequent primitive instructions, inaction occurs. In the 
case of a negative test instruction —a, the role of the value produced is reversed. 
In the case of a plain basic instruction a, the value produced is disregarded: 
execution always proceeds as if T is produced. The effect of a forward jump 
instruction #/ is that execution proceeds with the Z-th next instruction of the 
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Table 3. Axioms of PGA 



(x ; y) ; z = x ; (y ; z) 


PGA1 


{x n Y = x" 


PGA2 


x w ; y — x" 


PGA3 


{x;y) w =x;{y\xY 


PGA4 



program concerned. If I equals or the i-th next instruction does not exist, 
then ff^l results in inaction. The effect of the termination instruction ! is that 
execution terminates. 

PGA has the following constants and operators: 

- for each u 6 3, an instruction constant u ; 

- the binary concatenation operator _ ; _ ; 

- the unary repetition operator _ w . 

Terms are built as usual. Throughout the paper, we assume that there are in- 
finitely many variables, including x,y,z. 

We use infix notation for concatenation and postfix notation for repetition. 

Closed PGA terms are considered to denote programs. The intuition is that 
a program is in essence a non-empty, finite or infinite sequence of primitive in- 
structions. These sequences are called single pass instruction sequences because 
PGA has been designed to enable single pass execution of instruction sequences: 
each instruction can be dropped after it has been executed. Programs are consid- 
ered to be equal if they represent the same single pass instruction sequence. The 
axioms for instruction sequence equivalence are given in Table 3. In this table, 
n stands for an arbitrary natural number greater than 0. For each n > 0, the 
term x n is defined by induction on n as follows: x 1 — x and x n+1 = x ; x n . The 
unfolding equation x" = x ; x^ is derivable. Each closed PGA term is derivably 
equal to a term in canonical form, i.e. a term of the form P or P ; Q w , where P 
and Q are closed PGA terms that do not contain the repetition operator. 

Each closed PGA term is considered to denote a program of which the be- 
haviour is a finite-state thread, taking the set 21 of basic instructions for the set A 
of actions. The thread extraction operation |_| assigns a thread to each program. 
The thread extraction operation is defined by the equations given in Table 4 (for 
a G 21, I e N and u e J) and the rule given in Table 5. This rule is expressed 
in terms of the structural congruence predicate _ — _, which is defined by the 
formulas given in Table 6 (for n, m, I £ N and m, . . . , u n , v\, . . . , v m +i € 3). 

The equations given in Table 4 do not cover the case where there is an infinite 
chain of forward jumps. Programs are structural congruent if they are the same 
after removing all chains of forward jumps in favour of single jumps. Because 
an infinite chain of forward jumps corresponds to #0, the rule from Table 5 can 
be read as follows: if x starts with an infinite chain of forward jumps, then |a;| 
equals D. It is easy to see that the thread extraction operation assigns the same 
thread to structurally congruent programs. Therefore, the rule from Table 5 can 
be replaced by the following generalization: x = y => \x\ = \y\. 
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Table 4. Defining equations for thread extraction operation 



a\ = aoD |#i| = D 

a ; x\ = a o \x\ |#0 ; a;| = D 

+a\=aoD |#l;a;| = |a;| 

+a;x\ = \x\ <a> \#2 ; x\ \#l + 2 ; u\ = D 
-a|=aoD |#Z + 2 ; u; x\ = \#l + 1 ; x\ 

-a;x\ = |#2;a;| <a> |a| |!| = S 

|! ; ar| = S 

Table 5. Rule for infinite jump chains 



x * #0 ; y =» \x\ = D 

Table 6. Defining formulas for structural congruence predicate 

#n + 1 ; ui ; . . . ; m„ ; #0 = #0 ; Mi ; . . . ; u n ; #0 

#n + 1 ; ui ; . . . ; u„ ; #m = #m + n + 1 ; in ; . . . ; u„ ; #m 

(#n + i + 1 ; Mi ; . . . ; u„) u ^ (#/ ; m ; . . . ; u n ) w 

#m + n + / + 2 ; tti ; . . . ; tt„ ; («i ; . . . ; u m+ i )" = 

#n + Z + 1 ; Mi ; . . . ; w„ ; (vi ; . . . ; v m +i) w 

x^x 

xi = Mi A x 2 = J/2 => Xi ; a: 2 = Mi ; M 2 A xi u = yi" 



Let be a finite guarded recursive specification over BTA, and let Px be a 
closed PGA term for each X £ V(E). Let E' be the set of equations that results 
from replacing in E all occurrences of X by \Px\ for each X £ V(E). If E' 
can be obtained by applications of axioms PGA1-PGA4, the defining equations 
for the thread extraction operation and the rule for infinite jump chains, then 
\Px \ is the solution of E for X. Such a finite guarded recursive specification can 
always be found. Thus, the behaviour of each closed PGA term is a thread that 
is definable by a finite guarded recursive specification over BTA. Moreover, each 
finite guarded recursive specification over BTA can be translated to a closed 
PGA term of which the behaviour is the solution of the finite guarded recursive 
specification concerned (see Proposition 2 of [15]). 

Closed PGA terms are loosely called PGA programs. PGA programs in which 
the repetition operator does not occur are called finite PGA programs. 

4 The Program Notation PGLD 

In this section, we review a program notation which is rooted in PGA. This 
program notation, called PGLD, belongs to a hierarchy of program notations 
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introduced in [3]. PGLD is close to existing assembly languages. It has absolute 
jump instructions and no explicit termination instruction. 

In PGLD, as in PGA, it is assumed that there is a fixed but arbitrary finite 
set of basic instructions 21. Again, the intuition is that the execution of a basic 
instruction a may modify a state and produces T or F at its completion. 

PGLD has the following primitive instructions: 

— for each a G 21, a plain basic instruction a; 

— for each a £ 21, a positive test instruction +a; 

— for each a £ 21, a negative test instruction —a; 

— for each I e N, a direct absolute jump instruction 

PGLD programs have the form m; . . . ; u k , where u\, . . . , Uk are primitive in- 
structions of PGLD. We write Ppgld for the set of all PGLD programs. 

The plain basic instructions, the positive test instructions, and the negative 
test instructions are as in PGA. The effect of a direct absolute jump instruction 
is that execution proceeds with the l-th. instruction of the program con- 
cerned. If is itself the i-th instruction, then inaction occurs. If I equals or 
I is greater than the length of the program, then termination occurs. 

We define the meaning of PGLD programs by means of a function pgld2pga 
from the set of all PGLD programs to the set of all PGA programs. This function 
is defined by 

Pgld2pga(wi ; . . . ; u k ) = {4>i{ui) ; . . . ; (f> k (u k ) ; ! ; !) w , 

where the auxiliary functions <pj from the set of all primitive instructions of 
PGLD to the set of all primitive instructions of PGA are defined as follows 
(1 < 3 < k). 

= "J Xj<l<k, 

<M##0 = #fc + 2-(j-0 ifO</<j, 

<M##0 = ! if Z = V Z > fc , 

<f>j{u) = u if u is not a jump instruction . 

Let P be a PGLD program. Then pgld2pga(P) represents the meaning of 
P as a PGA program. The intended behaviour of P under execution is the 
behaviour of pgld2pga(P) under execution. That is, the behaviour of P under 
execution, written |-P| P gld: 

is |pgld2pga(P)|. 

We use the phrase projection semantics to refer to the approach to semantics 
followed in this section. The meaning function pgld2pga is called a projection. 

In the hierarchy of program notations introduced in [3], program nota- 
tions PGLA, PGLB and PGLC appear between PGA and PGLD. In [3], 
PGLD programs are translated into PGLC programs by means of a projec- 
tion pgld2pglc, etc. Above, pgld2pga is defined such that pgld2pga(P) = 
pgla2pga(pglb2pgla(pglc2pglb(pgld2pglc(P)))) for all PGLD programs P. 
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5 A Classification of Services 



In this short section, we provide a classification of services. It is a simplified 
version of the classification given in [9] and will be used in subsequent sections. 
A distinction is made between target services and para-target services: 

— A service is a target service if the result of the processing of commands by the 
service is partly observable externally. Reading input data from a keyboard, 
showing output data on a screen and writing persistent data in permanent 
memory are typical examples of using a target service. 

— A service is a para-target service if the result of the processing of commands 
by the service is wholly unobservable externally. Setting a timer and transfer- 
ring data by means of a Java pipe are typical examples of using a para-target 
service. 

The overall intuition about threads, target services and para-target services 
is that: 

— a thread is the behaviour exhibited by a sequential program on execution; 

— a thread interacts with services provided by the execution environment in 
question; 

— the intentions about the resulting behaviour pertain only to interaction with 
target services; 

— interaction with para-target services takes place only in as far as it is needed 
to obtain the intended behaviour in relation to target services. 

One of the assumptions made in thread algebra is that para-target services 
are deterministic. The exclusion of non-deterministic para-target services is a 
simplification. We believe however that this simplification is adequate in the cases 
that we address: para-target services that keep data for a thread. Of course, it 
is inadequate in cases where services such as dice-playing services are taken into 
consideration. Another assumption is that target services are non-deterministic. 
The reason for this assumption is that the dependence of target services on exter- 
nal conditions make it appear to threads that they behave non-deterministically. 

6 An Action Transforming Use Mechanism 

A thread may perform certain basic actions only for the sake of having itself 
affected by a service. When processing a basic action performed by a thread, a 
service affects that thread in one of the following ways: (i) by returning a reply 
value to the thread at completion of the processing of the basic action; (ii) by 
turning the processed basic action into another basic action. In this section, we 
introduce an action transforming use mechanism, which allows for para-target 
services to affect threads in either way. We will only use the action transforming 
use mechanism to have program behaviours affected by a para-target service. 
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The action transforming use mechanism is a generalization of the version of the 
use mechanism introduced in [7]. 2 

It is assumed that there is a fixed but arbitrary finite set of foci T and a fixed 
but arbitrary finite set of methods M. Each focus plays the role of a name of a 
service provided by the execution environment that can be requested to process 
a command. Each method plays the role of a command proper. For the set A of 
basic actions, we take the set {f.m /gf,m£ M}. Performing a basic action 
f.m is taken as making a request to the service named / to process command 
to. 

We introduce yet another sort: the sort S of services. However, we will not 
introduce constants and operators to build terms of this sort. We identify para- 
target services with pairs {H\,H2), where H\ : M + — > {T,F, M,B} and H 2 : 
M + — > .Atau) satisfying the following conditions: 3 

Vm e M ' 

(3a &M*>Hi{a^ (m)) = M ^Va'eM*. Hi(a' ~ (to)) {T, F}) , 

Va e M+,me M • [Hi{a) = B => Hi(a ^ (to)) = B) , 

VaeM+. (Hi (a) ^ M if 2 (a) = tau) . 

M stands for meaningless and B stands for blocked. M is used to indicate that a 
request to process a command is accepted, but that no reply is produced. B is 
used to indicate that a request to process a command is rejected. 

Let H be a para-target service, and let Hi and H 2 be the unique functions 
such that H = (Hi,H 2 ). Then we write rf(H) and af(H) for Hi and H 2 , 
respectively. Given a para-target service H and a method to G M, the derived 
service of H after processing to, written -§^H, is defined by rf(-J^-H)(a) = 
rf(H)((m)~a) and af(£;H)(a) = af(H)((m)~a). 

A para-target service H can be understood as follows: 

— if rf(H)((m)) e {T, F}, then the request to process m is accepted by the 
service, the reply rf(H)((m)) is produced, to is turned into tau, and the 
service proceeds as jj^H; 

— if rf(H)((m)) = M, then the request to process m is accepted by the service, 
no reply is produced, to is turned into af(H)((m)), and the service proceeds 
as -g-H; 

am ' 

— if rf(H)((m}) = B, then the request to process m is rejected by the service. 

The three conditions imposed on para-target services can be paraphrased as 
follows: 

2 In later papers, this use mechanism is also called thread-service composition. 

3 We write D* for the set of all finite sequences with elements from set D and we 
write D + for the set of all non-empty finite sequences with elements from set D. 
We use the following notation for finite sequences: ( ) for the empty sequence, (d) 
for the sequence having d as sole element, and a ^ a' for the concatenation of finite 
sequences a and a' . 
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Table 7. Axioms for action transforming use operators 



S // H = S 






ATU1 


D/ f H = D 






ATU2 


(tau o x) /f H = tau o (x // H) 






ATU3 


(x < g.m >y) /f H = (x // H) <3 c?.m > (y j s H) 






ATU4 


(x<f.m>y)/ f H = tou°{x/f &H) 


\frf(H)((m)) = 


T 


ATU5 


(x<f.m>y)/ f H = tauo{y/ f ^H) 


if r/(ff)«m» = 


F 


ATU6 


(x < f.m >y)/fH = 










if rf(H)((m)) = 


M 


ATU7 


(x < f.m>y) Is H = D 


if rf(H)({m}) = 


B 


ATU8 



— if it is possible that no reply is produced at completion of the processing of a 
command, then it is impossible that a positive or negative reply is produced 
at completion of the processing of that command; 

— after a request to process a command has been rejected, any request to 
process a command will be rejected; 

— a reply is produced at completion of the processing of a command if and 
only if the command is turned into tau. 

For each / G J 7 , we introduce the binary action transforming use operator 
.//.:TxS->T. Intuitively, p // H is the thread that results from processing 
all basic actions performed by thread p that arc of the form f.m by the para- 
target service H . When a basic action of the form f.m performed by thread p 
is processed by the para-target service H, it is turned into another action and, 
if this action is tau, postconditional composition is removed in favour of action 
prefixing on the basis of the reply value produced. 

The axioms for the action transforming use operators are given in Table 7. In 
this table, / and g stand for arbitrary foci from T and m stands for an arbitrary 
method from M. Axioms ATU3 and ATU4 express that the action tau and basic 
actions of the form g.m, where / ^ g, are not processed. Axioms ATU5-ATU7 
express that a thread is affected by a para-target service as described above 
when a basic action of the form f.m performed by the thread is processed by 
the service. Axiom ATU8 expresses that inaction occurs when a basic action to 
be processed is not accepted. 

Let T stand for either BTA or BTA+REC. Then we will write T+ATU for 
T, taking the set {f.m / e f,m 6 M} for A, extended with the action 
transforming use operators and the axioms from Table 7. 

The use mechanism introduced in [7] deals in essence with para-target ser- 
vices H for which it holds that af{H)(a) = tau for all a e M + . For these 
services, the action transforming use mechanism coincides with the use mecha- 
nism from [7]. 
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Table 8. Axioms for abstraction 



r tau (S) = S TT1 

Ttau(D) = D TT2 

Ttau(taU ox) = Txau{x) TT3 

Ttau (x < a > y) = r tau (a:) < a > r tau (y) TT4 

r tau (tau w ) = D TT5 



The action tau is an internal action whose presence matters. To conceal its 
presence in the case where it does not matter after all, we also introduce the 
unary abstraction operator r tau : T — > T. 

The axioms for the abstraction operator are given in Table 8. In this table, 
a stands for an arbitrary basic action from A. 

Abstraction can for instance be appropriate in cases where tau arises from 
turning actions of an auxiliary nature into tau by means of the action trans- 
forming use mechanism. In subsequent sections, abstraction will only be used 
in such cases. Unlike the use mechanism introduced in [7], the use mechanism 
introduced in [11] incorporates abstraction. 

Let T stand for either BTA+REC or BTA+REC+ATU. Then we will write 
T+ABSTR for T extended with the abstraction operator and the axioms from 
Table 8. 

7 State-Based Description of Para- Target Services 

In this section, we introduce the state-based approach to describe families of 
para-target services that will be used in Sections 8 and 11. This approach is 
similar to the approach to describe state machines introduced in [11]. 
In this approach, a family of para-target services is described by 

— a set of states S; 

— an effect function eff : M x S — > S; 

— a yield function yld : M x S — ► {T, F, M, B}; 

— an action function act : M. x S — > At 3U ] 

satisfying the following conditions: 

\/meM'(3seS' yld(m, s) = M => W £ S • yld(m, s') {T, F}) , 

3s e S • Vra e M • 

(yld(m, s) = B A Vs' 6 S • (yld(m, s') = B eff(m, s') = s)) , 

Vm e M, s e S • (yld(m, s) ^ M act(m, s) = tau) . 

The set S contains the states in which the services may be, and the functions 
eff, yld and act give, for each method m and state s, the state, reply and action, 
respectively, that result from processing m in state s. 
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We define, for each s G S, a cumulative effect function ceff s : M* — > S in 
terms of s and e/f as follows: 

ceff s (())=s, 

ceff s (a ^ (m)) = ejf (m, ceff s {a)) . 

We define, for each s 6 5, a para-target service H s in terms of ceff s , yld and 
aci as follows: 

rf(H s )(a ^ ( m )) = y ld(m, ceff 8 (a)) , 
af(H s )(a ^ (m)) = aci(m, ceff s (a)) . 

H g is called the para-target service with initial state s described by S, eff, yld 
and act. We say that {H s s G S} is the family of para-target services described 
by S, eff, yld and act. 

The conditions that are imposed on S, eff, yld and act imply that, for each 
s <E S, H s is indeed a para-target service. It is worth mentioning that = 
H eff( m ,s), rf(H s )((m)) = yld(m,s), and af(H s )((m)) = act(m,s). 

8 Method-to- Action Translator Services 

In this section, we give a state-based description of the very simple family of 
para-target services that constitute a register-file-dependent method-to-action 
translator of which the register file consists of registers that can contain natural 
numbers up to some bound. This method-to-action translator will be used in 
Section 9 to describe the behaviour of programs in a variant of PGLD with 
dynamically instantiated instructions. 

It is assumed that fixed but arbitrary positive numbers I, N G N have been 
given. / is considered the number of registers in the register file and N is con- 
sidered the greatest natural number that can be contained in the registers of the 
register file. The functions from [1,/] to [0,iV] are taken for the states of the 
register file. For every function s : [1, /] — > [0, N], s is the state in which, for each 
i G [1, 1}, the content of register i is s(i). 

It is also assumed that a fixed but arbitrary set -4 pro to Q M- and a fixed but 
arbitrary function 9 : A pro to x ([1,/] — > [0, AT]) — ► A have been given. ^t pro to is 
considered the set of methods that are transformable to basic actions and 6 is 
regarded to give, for each method m in „4 pro to and function s : [1, 1} — > [0, N], the 
basic action into which m is turned in the case where the state of the register 
file is s. The methods that belong to -4 pr oto are called proto- actions because they 
are the methods that are turned into basic actions by the register-file-dependent 
mcthod-to-action translator. 

The register-file-dependent method-to-action translator services accept the 
following methods: 

— for each i G [1,1] and n G [0,7V], a register set method set:i:n; 

- each m G -4 pro to- 
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We write -M 5e t for the set {set:z:n | i 6 [1,7] An 6 [0,7V]}. It is assumed that 

M set C M. 

The methods accepted by the method-to-action translator services can be 
explained as follows: 

— set:i:n: the content of register i becomes n, the reply is T, and set:i:n is 
turned into tau; 

— m, where to £ -4 pra to: the state of the register file does not change, there is 
no reply, and m is turned into 9{m, s) where s is the state of the register file. 

Let RFS be the set of all functions s : [1,7] ->■ [0,7V]. Take t such that 
t i RFS. Let s £ RFS U {f}. Then we write RFDT S for the para-target service 
with initial state s described by S = RFS U {f } and the functions eff, yld, and 
act defined as follows (i £ [1,7], n £ [0,7V], and p £ RFS): 4 



eff(set:i:n,p) = 


(90 [i i-> 


n] , 5 


eff{m, p)= p 


if m 


^ v4.p r oto ? 


eff(m, p) = T 


if TO 


^ X set U ^lp ro to 


e#(m, T) = T , 






yld(set:i:n, p) = 


T, 




yld(m, p) = M 


if to 


£ -^proto j 


yld(m, p) = B 


if to 


£■ X 5et U ^lp ro to 


j/id(m, T) = B , 






act(m, p) = 9(m, p) if m 


£ -^proto j 


act(m, p) = tau 


if TO 


^ -^proto j 


act(m, |) = tau 







We write RFDT init for i?77?r [lMO ]e...©[/^o] • 

The special state | added above to the proper states of the register file is 
a state in which any request to process a method is rejected. The existence of 
such a blocking state is required to guarantee that S, eff, yld and act describe 
a para-target service. 

The following proposition states rigorously that the methods that belong to 
-4proto are exactly the methods that are turned into basic actions. 

Proposition 1. For all s : [1,7] -» [0,7V]: 

Aroto = {meM\3aeM*' af (RFDT s )(a ~ ( m )) <= A} . 

Proof. This follows immediately from the definition of the register-file-dependent 
method-to-action translator services. 

4 We use the following notation for functions: / © g for the function h with dom(ft) = 
dom(/) U dom(<;) such that for all d £ dom(fe), h(d) — f(d) if d £ dom(<;) and 
h(d) = g(d) otherwise; and [d i— ► r] for the function / with dom(/) = {d} such that 
f(d) 
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9 PGLD with Dynamically Instantiated Instructions 

In this section, we introduce a variant of PGLD with dynamically instantiated 
instructions. This variant is called PGLDdii. In Section 10, the usefulness of 
dynamic instruction instantiation will be illustrated by means of an example. 

In PGLDdii, it is assumed that there is a fixed but arbitrary finite set of foci 
T with rfdt e T and a fixed but arbitrary finite set of methods M. Moreover, 
we adopt the assumptions made about register-filc-dcpendent mcthod-to-action 
translator services in Section 8. The set {f.m \ f G J 7 , m G M. \ -4 pr oto} is taken 
as the set 21 of basic instructions. In the setting of PGLDdii, we use the term 
proto-instruction instead of proto-action and write 2t pro to instead of ^4 pro to- A 
proto-instruction is what becomes a basic instruction by dynamic instantiation. 

PGLDdii has the following primitive instructions in addition to the primitive 
instructions of PGLD: 

— for each e G 2t proto , a plain basic proto-instruction e; 

— for each e E 2l proto , a positive test proto-instruction +e; 

— for each e £ 2l pro to, a negative test proto-instruction — e. 

PGLDdii programs have the form m ; . . . ; Uk, where u\,...,Uk are primitive 
instructions of PGLDdii- 

The effect of a plain basic proto-instruction e is the same as the effect of the 
plain basic instruction 6(e, s), where s is the state of the register file involved in 
the instantiation of proto-instructions. The effect of a positive or negative test 
proto-instruction is similar. 

Recall that the content of register i can be set to n by means of the basic 
instruction rfdt.set:i:n. Initially its content is 0. 

We define the meaning of PGLDdii programs by means of a function 
pglddii2pgld from the set of all PGLDdii programs to the set of all PGLD 
programs. This function is defined by 

pglddii2pgld(ui ;...;v,k) = ip(ui) ; . . . ; ip(uk) , 

where the auxiliary function ip from the set of all primitive instructions of 
PGLDdii to the set of all primitive instructions of PGLD is defined as follows: 

ip(e) = rfdt.e if e e 2l pr . to , 
ip(+e) = +rfdt.e if e G 2l proto , 
tp(—e) = -rfdt.e if e G 2l proto , 
ip(u) = u if u is not a proto-instruction . 

The idea is that each proto-instruction can be replaced by an instruction in 
which the proto-instruction is taken for the method. 

Let P be a PGLDdii program. Then pglddii2pgld(P) represents the 
meaning of P as a PGLD program. The intended behaviour of P under ex- 
ecution is the behaviour of pglddii2pgld(_P) under execution on interac- 
tion with a register-filc-dependent method-to-action translator when abstracted 
from tau. That is, the behaviour of P under execution, written \P\ 

PGLD j ■ - i IS 

PGLD / rfdt RFDT iDit ). 
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10 Concrete Proto-Instructions 



At a fairly concrete level, basic instructions and proto-instructions are strings 
of characters. In [3], a concrete notation for basic instructions is introduced for 
the case where each basic instruction consists of a focus and a method. Here, we 
extend that concrete notation to cover proto-instructions. The resulting concrete 
notation will be used in examples of the use of PGLD dii . 

First of all, we distinguish neutral strings and active strings. A neutral string 
is an empty string or a string of one or more characters of which the first character 
is a letter or a colon and each of the remaining characters is a letter, a digit or 
a colon. An active string is a string of two or more characters of which the first 
character is an asterisk and each of the remaining characters is a digit. 

A concrete proto-instruction is a string of the form f'.m', where /' and m' 
are non-empty strings of characters in which neutral strings and active strings 
alternate, starting with a neutral string of which the first character is a letter, 
and at least one active string occurs. 

A concrete focus is a neutral string of which the first character is a letter. A 
concrete method is either a neutral string of which the first character is a letter 
or a concrete proto-instruction. A concrete instruction is a string of the form 
/.m, where / is a concrete focus and m is a concrete method. 

The intention is that instantiation of a concrete proto-instruction amounts 
to simultaneously replacing all active strings occurring in it by strings according 
to some assignment of strings to active strings. The assignment concerned must 
be such that concrete proto-instructions are turned into concrete instructions. 

To accomplish the assignments of strings to active strings, all active strings 
of interest must be of the form *8, where 5 is the decimal representation of some 
i £ [1,/]- Moreover, an encoding of the assignable strings by numbers in [0,N] 
must be given. Then each state of the register file being involved in PGLDdii 
induces an assignment as follows: for each active string of interest, say *S, the 
string assigned to it is the one that is encoded by the content of the register with 
the number of which 5 is the decimal representation. 

The concrete notation for basic instructions introduced above is sufficiently 
expressive for all applications that we have in mind. The assignable strings are in 
many cases binary or decimal representations of numbers in the interval [0, N}. 
In such cases, it is most natural to encode the representations simply by the 
numbers that they represent. 

Example 1. Consider a program that on execution reads digit by digit the binary 
representation of a password and then performs an action to have the password 
checked by some para-target service. The binary representation of a password is a 
character sequence of a fixed length, say n, of which all characters are among the 
binary digits and 1. The program reads in the binary digits which make up the 
binary representation of the password by performing actions that are processed 
by a target service. Suppose that the service used for reading in binary digits 
only accepts methods of the form getb and returns the reply F if the next binary 
digit is and T if the next binary digit is 1. Moreover, suppose that the service 
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used for checking passwords only accepts methods of the form chk:pw, where pw 
is the binary representation of a password. The focus stdin is used below as a 
name of the former service and the focus passw is used below as a name of the 
latter service. 

In PGLDdu, where proto- instructions are available, the program has to distin- 
guish among only 2-n cases. In PGLD, where no proto-instructions are available, 
the program has to distinguish among 2™ cases. 

Take I = n and N = 1. Consider the case where n = 3. In PGLDdii, the 
initial part of the program looks as follows: 

+stdin.getb ; ##5 ; rfdt.set:l:0 ; ##6 ; rfdt.set:l:l ; 
+stdin.getb ; ##10 ; rfdt.set:2:0 ; ##11 ; rfdt.set:2:l ; 
+stdin.getb ; ##15 ; rfdt.set:3:0 ; ##16 ; rfdt.set:3:l ; 
+passw.chk:*l:*2:*3 ; . . . 

In PGLD, the initial part of the program looks as follows: 
+stdin.getb ; ##7 ; ##4 ; 

+stdin.getb ; ##13 ; ##10 ; +stdin.getb ; ##19 ; ##16 ; 
+stdin.getb ; ##23 ; ##22 ; +stdin.getb ; ##25 ; ##24 ; 
+stdin.getb ; ##27 ; ##26 ; +stdin.getb ; ##29 ; ##28 ; 
+passw.chk:000 ; ##44 ; ##45 ; +passw.chk:001 ; ##44 ; ##45 ; 
+passw.chk:010 ; ##44 ; ##45 ; +passw.chk:011 ; ##44 ; ##45 ; 
+passw.chk:100 ; ##44 ; ##45 ; +passw.chk:101 ; ##44 ; ##45 ; 
+passw.chk:110 ; ##44 ; ##45 ; +passw.chk:lll ; . . . 

These programs take 16 and 43 instructions, respectively, up to and including 
the password-check (proto-)instructions. In general, we have that: 

— In PGLDdii, the program takes 5 • n + 1 instructions up to and including the 
password-check proto-instruction; 

- In PGLD, the program takes 6 • (2" — 1) + 1 instructions up to and including 
the last password-check instruction. 

11 Register File Services 

In this section, we give a state-based description of the very simple family of 
para-target services that constitute a register file consisting of registers that can 
contain natural numbers up to some bound. This register file will be used in 
Section 12 to describe the behaviour of programs in PGLDdii- 

As in Section 8, it is assumed that fixed but arbitrary positive numbers 
I,N e N have been given. I is considered the number of registers in the register 
file and N is considered the greatest natural number that can be contained in 
the registers of the register file. 

The register file services accept the following methods: 
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— for each i e [1,7] and n e [0, iV], a register set method set:z:n; 

— for each i G [1, J] and n <G [0,N], a register test method eq:i:n. 

We write M r f for the set {set:i:n,eq:i:n \ i E [1,7] An G [0,7V]}. It is assumed 
that X rf C 7W. 

The methods accepted by register services can be explained as follows: 

— set:i:n: the content of register i becomes n, the reply is T, and set:i:n is 
turned into tau; 

— eq:i:n: the content of the register does not change, the reply is T if the 
content of register i equals n and F otherwise, and eq:i:n is turned into tau. 

Let RFS be the set of all functions s : [1,1] -> [0,N]. Take | such that 
t ^ RFS. Let s e RFS U {']}. Then we write RF S for the para-target service 
with initial state s described by S = RFS U {|} and the functions eff , yld, and 
act defined as follows (i <E [1,7], n 6 [0,7V], and p e HFS): 

eff(set:i:n, p) ~ p®[i^ n] , 
eff(eq:i:n,p) = p , 



yld(m, T) = B , 

act(m, p) = tau , 
act(m, |) = tau . 

We write RF init for i?7 1 [lM0]e ... (B[jM0] . 

12 An Alternative Semantics for PGLDdn 

In this section, we discuss an alternative semantics for PGLDdii- 

Unlike the meaning of PGLDdii programs that we defined in Section 9, we 
define the alternative meaning of PGLDdii programs only for the case where 
7=1. The generalization of the definition to arbitrary 7 is obvious, but leads to 
a definition that is hard to read. 

The alternative meaning of PGLDdii programs is given by a function 
pglddii2pgld' from the set of all PGLDdii programs to the set of all PGLD 
programs. For the case where 7=1, this function is defined by 

pglddii2pgld'(ui ; . . . ; u k ) = ^[(ui) ; . . . ; ip' k ( u k) , 



eff(m, p) = T 
eff(m, T) = T 



if m ^ M r f , 



yld(set:i:n, p) = T , 
yld(eq:i:n, p) = T 
yld(eq:i:n, p) = F 
yld(m, p) = B 



if p{i) = n 
if p(i) + n 
if m .M r f 
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where the auxiliary functions tp'j from the set of all primitive instructions of 
PGLDdii to the set of all PGLD programs are defined as follows (1 < j < k): 

Me) = +rf.eq:l:0 ; ##Z" ; 



+rf.eq:l:iV-l ; ##Z£ JV _ 1 ; 
9(e,0);##l' j+1 ;##l' j+2 ; 

6(e,N-l);##l> j+1 ;##l' j+2 ;6(e,N) , 
^■(+e) = +rf.eq:l:0 ; ##i£ ; 



+rf.eq:l:iV-l ; ##/V JV _ 1 ; ; 



+6(e, N-l) ; ; ##Z; +2 ; +6(e, N) 

$(-e) = +rf.eq:l:0 ; ; 

+rf.eq:l:AT-l ; ##/V JV _ 1 ; ##1>> N ; 
-%,0) ;##/; +2 ; 



-0(e, ; ; ##Z; +2 ; -0(e, AT) 



^'•(rfdt.m) = rf 



.m 



^/•(+rfdt.m) = +rf.m , 
rfdt.m) = — rf.m , 

^•(##0 =##/(, 

V'j(u) = u if u is not a proto-instruction, jump instruction or 

a plain basic or test instruction with focus rfdt , 

and for each j e [1, k] and /i G [0, N}: 

I'j =j + (5-N+l)- nj , 
l'l h = l' j +2-N + 3-h + l, 

and rij is the number of proto- instructions preceding position j. 

The idea is that each proto-instruction can be replaced by an instruction 
sequence of which the execution leads to the execution of the intended instruction 
after the content of the register has been found by a linear search. Because 
the length of the replacing instruction sequence is greater than 1, the direct 
absolute jump instructions are adjusted so as to compensate for the introduction 
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of additional instructions. Obviously, the linear search for the content of the 
register can be replaced by a binary search. 

Henceforth, we will proceed as if pglddii2pgld' has been defined for arbi- 
trary /. 

Let P be a PGLDdu program. Then pglddii2pgld'(P) represents an alter- 
native meaning of P as a PGLD program. The alternative behaviour of P under 
execution is the behaviour of pglddii2pgld'(P) under execution on interaction 
with a register file when abstracted from tau. That is, the alternative behaviour of 
P under execution, written |-P|p GLDdii : is T tau (|pglddii2pgld'(P)| PGLD / rf RF init ). 

Example 2. Consider the PGLDdu program from Example 1. The initial part of 
the PGLD program that results from its translation by means of pglddii2pgld 
looks as follows: 

+stdin.getb ; ##5 ; rfdt.set:l:0 ; ##6 ; rfdt.set:l:l ; 
+stdin.getb ; ##10 ; rfdt.set:2:0 ; ##11 ; rfdt.set:2:l ; 
+stdin.getb ; ##15 ; rfdt.set:3:0 ; ##16 ; rfdt.set:3:l ; 
+rfdt.passw.chk:*l:*2:*3 ; . . . 

The initial part of the PGLD program that results from its translation by means 
of pglddii2pgld' looks as follows: 

+stdin.getb ; ##5 ; rf.set:l:0 ; ##6 ; rf.set:l:l ; 
+stdin.getb ; ##10 ; rf.set:2:0 ; ##11 ; rf.set:2:l ; 
+stdin.getb ; ##15 ; rf.set:3:0 ; ##16 ; rf.set:3:l ; 
+rf.eq:l:0;##19;##22; 
+rf.eq:2:0;##25;##28; 
+rf.eq:2:0;##31;##34; 
+rf.eq:3:0;##37;##40; 
+rf.eq:3:0 ; ##43 ; ##46 ; 
+rf.eq:3:0 ; ##49 ; ##52 ; 
+rf.eq:3:0;##55;##58; 
+passw.chk:000 ; ##59 ; ##60 ; 
+passw.chk:001 ; ##59 ; ##60 ; 
+passw.chk:010 ; ##59 ; ##60 ; 
+passw.chk:011 ; ##59 ; ##60 ; 
+passw.chk:100 ; ##59 ; ##60 ; 
+passw.chk:101 ; ##59 ; ##60 ; 
+passw.chk:110 ; ##59 ; ##60 ; 
+passw.chk:lll ; . . . 

These PGLD programs take 16 and 58 instructions, respectively, up to and 
including the password-check instructions. 
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Let b\, &2 and 63 be either or 1. Suppose that the three bits read in at 
the beginning of the execution of these programs are &i, 6 2 and 63, in that 
order. In the case of the former program, it is easy to check that the instruction 
+rfdt.passw.chk:*l:*2:*3 will be executed while the contents of registers 1, 2 and 
3 are b\, bi and 63, respectively. In the case of the latter program, it is easy to 
check that the instruction +passw.chk:6 1 & 2 ^3 will be executed after execution of 
some test and jump instructions. This strongly suggests that the programs are 
"behaviourally equivalent" . 

The following theorem states rigorously that, for any PGLDdu program, the 
behaviour under execution coincides with the alternative behaviour under exe- 
cution. 

Theorem 1. For all PGLDdn programs P, |-P| PG LD dii = |-P|p G ld ■■■ 

Proof. Strictly speaking, we prove this theorem in the algebraic theory obtained 
by: (i) combining PGA with BTA+REC+ATU+ABSTR, resulting in a theory 
with three sorts: a sort P of programs, a sort T of threads, and a sort S of 
services; (ii) extending the result by taking |_| for an additional operator from 
sort P to sort T and taking the semantic equations and rule defining thread 
extraction for additional axioms. We write T for the set of all closed terms of 
sort T from the language of the resulting theory. 

In the proof, we make use of an auxiliary function |_,_| : N x V PG ld — ► 
which gives, for each natural number i and PGLD program ui ; . . . ; u k , a closed 
term of sort T that denotes the behaviour of u\ ; . . . ; u k when executed from 
position i if 1 < i < k and S otherwise. This function is defined as follows: 

; . . . ; u k \ = \4>i{ui) ; . . . ; 4> k (u k ) ; ! ; ! ; (<M«i) ! • • • ! ^fe( u fe) I ! ; 01 

if 1 < i < k , 

\i, ui ; . . . ; u k \ = S if -1 1 < i < k 

(where <f>j is as in the definition of pgld2pga) . It follows easily from the definition 
of _, _| and the axioms of PGA that if 1 < i < k: 

\i,ui ; . . . ; u k \ = a o \i + l, Ul ; . . . ; u k \ if Ui = a , 

\i,ui ; . . . ; u k \ = \i + ; . . . ; u k \ <a> \i + 2, u x ; . . . ; u k \ if u. t = +a , 
\i,ui ; . . . ; u k \ = \i + 2,m ; . . . ; u k \ < a> \i + 1, m ; . . . ; u k \ if u t = -a , 
\i, ui ; . . . ; u k \ = \l, ui ; . . . ; u k \ if Ui = ##l . 

Let vi, . . . ,v k be primitive instructions of PGLDdu, let 

T = {r tau (\i, V'K) ; • • • ; Afdt RFDT S ) \ i G [1, k] A a : [1, 1] - [0, N}} , 

T' = {r tau (|^ ; • ■ ■ ; A RFs) I < e [l, k] a s ■. [1, /] - [o, N}} 

(where tp, ipj, /■ are as in the definitions of pglddii2pgld and pglddii2pgld'), 
and let [3 : T —* T' be the bijection defined by 

/3(r t au(N, V(«i) ; • • ■ ; Afdt rfdt b )) 

= T tau (\l' l ^' 1 (v 1 ):...;^ k (v k )\/ rf RF s ) . 
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For each p' G T, write (3*(p') for p' with, for all p E T, all occurrences of p in 
p' replaced by (3(p). Then, using the equations concerning the auxiliary function 
|_, _| given above, it is straightforward to prove that there exists a set E consisting 
of one derivable equation p = p' for each peT such that, for all equations p = p' 
in E: 

— the equation [3(p) = (3*{p') is derivable; 

— p' ET only if p' can be rewritten to a p" E'T using the equations in E from 
left to right. 

Because \^{v\) ; . . . ; ^{v k )\ = |l,V(«i) ; • • ; ^(ufc)l and l^'iM "4>' k ( v k)\ = 
\l[,ip[(vi) ; . . . ; tp' k (vh)\, this means that \v x ; . . . ; v fe | PGLDd .. and \v 1 ;.. . ; Vfc| PGLDdii 
are solutions of the same guarded recursive specification. Because guarded re- 
cursive specifications have unique solutions, it follows immediately that \vi;...; 

W fc|pGLD dii — \ V 1 i • • ■ i U fc|pGLD dii - 



13 Discussion of Semantic Approaches 

In Sections 9 and 12, the meaning of PGLDdii programs is explained by means 
of different translations into PGLD programs. In both sections, the intended 
behaviour of a PGLDdii program under execution is described as the behaviour 
of the translated program under execution on interaction with some para-target 
service. The translation from Section 9 is extremely simple, but the translation 
from Section 12 is fairly complicated. The para-target service used in Section 9 
to describe the behaviour of a PGLDdu program and the one used in Section 12 
are equally simple. However, the former service is far more powerful: it turns 
a processed method into a basic action if the method corresponds to a proto- 
instruction. By its power, the translation can be kept simple if that service 
is used. Because of the simpler translation of PGLD dii programs into PGLD 
programs and the equally simple para-target service used, the approach followed 
in Section 9 to define the meaning of PGLDdii programs is preferable. 

A manifestation of the difference in complexity of the translations of PGLDdii 
programs from Sections 9 and 12 is that the former translation replaces each 
primitive instruction of PGLDdii by one primitive instruction of PGLD, whereas 
the latter translation gives rise to a combinatorial explosion. Recall that I stands 
for the number of registers involved in the instantiation of proto-instructions 
and N stands for the greatest natural number that can be contained in those 
registers. The translation from Section 12 replaces each primitive instruction of 
PGLDdii that is not a proto-instruction by one primitive instruction of PGLD 
as well, but replaces each proto-instruction by a sequence of 

(2 • N + 1) ■ ELi( N + + 3 • {(N + I) 1 - 1) + 1 
= (5 ■ N + I) ■ (((N + l) 1 - 1)/N) + 1 

primitive instructions of PGLD. 

If a new programming feature is added to a known program notation such 
as PGLD and the starting point of the approach to define the meaning of the 
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programs from the extended program notation is translation of those programs 
into programs from the known program notation, then we can conceive of several 
approaches: 

— give a translation by which each program from the extended program no- 
tation is translated into a program from the known program notation that 
exhibits on execution the same behaviour; 

— give a translation by which each program from the extended program no- 
tation is translated into a program from the known program notation that 
exhibits on execution the same behaviour by interaction with a given para- 
target service that does not turn any processed method into a basic action; 

— give a translation by which each program from the extended program no- 
tation is translated into a program from the known program notation that 
exhibits on execution the same behaviour by interaction with a given para- 
target service that turns certain processed methods into basic actions. 

We consider an approach earlier in this list preferable provided that the trans- 
lation concerned does not become too complicated. In the case where the trans- 
lation becomes too complicated with all three approaches, it is desirable to look 
for another starting point. This may end up in direct thread extraction, i.e. 
assigning a thread to each program as this was done for PGA in Section 3. 

In the case of PGLDdii, it is obvious that the first approach in the list given 
above does not work. However, it is virtually impossible to find out that the third 
approach is preferable to the second one without actually producing definitions 
of the meaning of PGLDdu programs according to both approaches. 

14 Conclusions 

We have studied sequential programs that are instruction sequences with dynam- 
ically instantiated instructions. We have defined the meaning of the programs 
concerned in two different ways, which both involve a translation into programs 
that arc instruction sequences without dynamically instantiated instructions. In 
one of the two ways, the translation is very simple and does not lead to increase 
in the length of a program or the number of steps needed by a program. That way 
is considered the preferred one. The preferred way made it necessary for the use 
mechanism that was introduced in [7] to be generalized. In [6], we demonstrate 
that dynamic instruction instantiation is a useful programming feature. 

In this paper, we have followed the approach of projection semantics, start- 
ing from the perception of a program as an instruction sequence. This means 
that programs are considered at a much lower level than usual in theoretical 
computer science. This allows for bringing the interface between software and 
hardware better into the picture, which becomes increasingly important to a 
growing number of developments related to computer architecture. The usual 
approaches to define the meaning of programs, such as operational semantics, 
dcnotational semantics and axiomatic semantics, are based on the view that the 
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details of program execution should be abstracted from as much as possible. 
This makes comparisons with those approaches virtually impossible. 

In [10], we have modelled and analysed micro-architectures with pipelined 
instruction processing in the setting of program algebra, basic thread algebra, 
and Maurcr computers [13, 14]. In that work, which we consider a preparatory 
step in the development of a formal approach to design new micro-architectures, 
dynamically instantiated instructions were not taken into account. An option for 
future work is to look at the effect of dynamically instantiated instructions on 
pipelined instruction processing. 
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